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Technical Field 

[0003] This invention pertains to distributed computer network node naming resolution 
processes and, more specifically, to registration of Internet domain names. 

Background of the Invention 
[0004] In distributed computer networks, being able to locate individual computers, 
servers, or various other machines on the network is critical. On the Internet, one of the 
most valuable identification resources is the domain name. Internet domain names provide 
a convenient way to reference Internet Protocol (IP) numerical addresses. Presently, IP 
addresses are 32-bit integers. They comprise four numbers separated by periods. Every 
"host" machine (e.g., computer, etc.) connected to the Internet must be identifiable by a 
specific numerical IP address. However, people prefer to reference host machines by 
pronounceable, easily remembered names, referred to as "domain names." The Internet 
implements a Domain Name System (DNS) to facilitate matching specific domain names to 
specific hosts. 
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[0005] The DNS is a distributed database system that allows computer applications to 
map between domain names and IP addresses. The DNS also provides electronic mail 
routing information and many other services. Individual components of the DNS 
distributed database can be cached locally, or stored on any of numerous distributed 
machines. The DNS database data correlates each domain name to a specific numeric IP 
address. If a computer's local cache does not have the information to resolve a domain 
name into an IP address, it sends a request to other computers that may contain the 
resolution information. The DNS affords a domain name some measure of independence 
from the physical location of a host. The host can be moved to a new location on the 
network, but it can still be accessed using the same domain name. As long as a user can 

M= remember the domain name, the host can always be located, even if the IP address changes 

O 

Q over time. This illustrates the value of a domain name that is easy to remember. 
m [0006] Physically, the DNS comprises many servers and other computers or machines 
s t" that run software and store data permitting computers to query the DNS database. One 
m such machine is the "root server. " A root server is a server computer that maintains the 
U software and data necessary to locate "name servers" that contain authoritative data for a 
p specific domain, such as the " .com" top level domain. There are presently thirteen root 
K servers throughout the world. Name servers are computers that have the software and data 
P to resolve the domain name into an IP address. The data accessible through the name 

server is often referred to as a "zone file." A "zone" is a subset of the total domain name 
space. The domain names in that subset are stored in the zone file for that name server. 
There is a zone file for each domain space (i.e., zone). 

[0007] The DNS is organized in a hierarchical, tree structure. A domain name is the 
label representing a specific domain within the total possible domain space available in the 
DNS. The highest level in the DNS hierarchy is the "root," which is technically unnamed 
but often referred to as the " . " or "dot. " The level immediately below the root in the DNS 
hierarchy is the top-level domain, or "TLD." It is called the "top-level domain" because it 
is the highest level in the hierarchy after the root. The TLD appears furthest to the right in 
an English-language domain name. For example, "gov" in the "uspto.gov" domain name. 
There are various types of TLDs. The term "gTLD" is often interchangeably used to refer 
to a "global top-level domain" or a "generic top-level domain." A global TLD is one that 
can be registered by an entity regardless of the entity's geographic location or political 
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boundary. For example, a person, corporation, or other entity located anywhere in the 
world can register a name in the ".com" domain. However, because an entity must have a 
presence in the United Kingdom to register a name in the " .uk" TLD, that domain is not a 
global TLD. Similarly, a generic TLD represents a domain in which an entity can register 
a name regardless of what type of entity it is. For example, because any entity can register 
a name in the ".com" domain, while only military entities can register a name in the ".mil" 
domain, the ".com" domain is an example of a generic TLD and the ".mil" domain is an 
example of a "specific TLD." The ".uk" domain is also an example of a "country code" 
TLD, or "ccTLD," applicable to the United Kingdom. Other examples of ccTLDs include 
".fr" for France, ".ca" for Canada, ".jp" for Japan, and ".us" for the United States of 
p America. 

5 [0008] By registering a domain name in a particular TLD, the TLD is sub-divided into 
^ lower levels in the DNS hierarchy. A second-level domain (SLD) is the level in the DNS 
2i hierarchy immediately below the TLD. An example of a second-level domain would be 
J° "snapnames" in the "snapnames.com" domain name. The level in the DNS hierarchy 
f" immediately below the second-level domain is the third-level domain. An example of the 
fa third-level domain would be "portland" in the "portland.or.us" domain name. Further 

l=A-. 

Q subdivisions can be created in a similar manner. Domain names at each level of the 

f ~ 5 hierarchy must be unique. Thus, while there can be only one "snapnames" registered in 

the ".com" TLD, there can be a "snapnames.net" domain name in addition to the 

"snapnames.com" domain name. 

[0009] Historically, domain name registration has been conducted through a Shared 
Registration System (SRS) involving registries, registrars, and registrants. The SRS was 
created by Network Solutions, Inc. in 1999 to provide a registry backend through which 
multiple, globally diverse registrars could register domain names. The term "registry" 
refers to the entity responsible for managing allocation of domain names within a particular 
name space, such as a TLD. One example of a registry is the VeriSign registry for the 
.com, .org, and .edu TLDs. The term "registrar" refers to any one of several entities with 
authority to issue commands or requests to add, edit, or delete registrations to or from the 
registry for a name space. Entities that wish to register a domain name do so through a 
registrar. The term "registrant" refers to the entity registering the domain name. In some 
name spaces, the registry and registrar functions can be performed by the same entity. The 
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combined registry-registrar model is implemented in many ccTLDs. The overall 
registration system, including multiple registries, is overseen by the Internet Corporation 
for Assigned Names and Numbers (ICANN). ICANN is a non-profit corporation that was 
formed to assume responsibility for the IP address space allocation, protocol parameter 
assignment, domain name system management, and root server system management 
functions previously performed under U.S. Government contract by the Internet Assigned 
Numbers Authority (I AN A) and other entities. 

[0010] Domain names, or more specifically domain name registrations, have become 
significant business (and personal) assets. Registration rights are now bought, sold, traded, 
bartered, auctioned and stockpiled in "inventories." Some domain names have been 
H transferred for consideration on the order of tens or even hundreds of thousands of U.S. 
O dollars. At the time of this writing, Verisign, Inc.— the company that maintains the .com, 
If! .net, and .org gTLD registry— reports over 32 million registrations in its database. 
% Industry statistics indicate, however, that only about 10% of the domain names registered 
OB are currently in actual use, including more than just a simple holding or redirection page. 
¥» Many registrations are the work of speculators. 

Pi [0011] The actual cost to register an available domain name at present is relatively 
!J nominal, ranging from $6.50 to $35 per year. This charge is assessed by the domain name 
K registrar to attend to entering the registration on the registry, and to maintain corresponding 
records. It represents a markup over the wholesale fee charged by the registry. There are 
numerous qualified registrars for the common gTLDs, so the market for this service is 
competitive. The registrar business can be viable because it can be largely automated and 
operated through a Web site so that direct costs are low. Volume is key, however, so much 
effort and money is spent on advertising and various relationships with other sites to attract 
"traffic. " The leading registrars today each process on the order of a few million 
registrations or renewals per year. 

[0012] New gTLDs are being added as the older ones — .com .net .org — become 
saturated. The realm of possible names under a given gTLD is not the problem, it is 
immense. (Names up to 67 characters long, plus the extension, apparently can be 
registered today.) The trouble is that popular, easy to remember or easy to recognize 
names are relatively limited in number. Many of the most desirable domain names, those 
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corresponding to well-known trademarks or generically describing commercial goods or 
services, are long since taken in the basic gTLD spaces. 

[0013] Acquisition of a desirable domain name requires current information as the 
registry is changing constantly. Each registry operator disseminates updates to the 
corresponding domain name resolution servers around the world on at least a daily basis. 
One can expect this update frequency to rise toward substantially continuous. The public 
can access the registry directly in a "read only" fashion; in other words, the public can 
view information but not change it. Presently, this ability is generally implemented by the 
registry maintaining a public Web site (or ftp site) where anyone can get information. The 
WHOIS lookup, or similar functions provided by the Registry or individual registrars, can 
H be used to identify the registrant of a given domain name. Various sites now offer these 

3 kinds of lookups, though they merely query the actual registries and/or registrar databases 

H 

ff% to acquire the data. 

f. [0014] The challenge arises in that many users or entities are "watching" for 

ffi availability of the very same names at the very same registries. The "winner" is the 

U registrar (or individual scripting through the registrar's connections to the registry) who can 

q "grab" (register) the newly released name before anyone else. It may have substantial 

^ resale value. Indeed, the registrar likely already has a buyer in the queue to whom to 

Q 

£* register the domain name. In any event, grabbing the name is a high-tech race where only 
first place wins. It is considered common knowledge in the industry that the winners are 
nearly always technologically sophisticated professional speculators, who either script 
through a registrar's connections without the registrar's knowledge, or strike arrangements 
with registrars for preferential access. It is also axiomatic that the average domain buyer 
has practically no chance of registering a valuable deleting name, a state of affairs the 
present invention would remedy. 

[0015] To effect a registration (renewal), domain name registrants or users must work 
through a qualified registrar; registrants do not have direct access to the registry (except a 
read-only lookup or search.) In large part, this is due to the implementation of an SRS, or 
Shared Registration System. There is only one registry for each gTLD, as domain names 
must be unique globally. Each registrar qualified to service a particular gTLD has 
electronic access— typically a secure digital communication channel-for interacting with the 
corresponding registry, for example to enter or purge a domain name registration. A 
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registration is purged, for example, if the registrant does not timely pay a renewal fee (after 
a grace period). 

[0016] The link between a registrar and the registry employs a Registry— Registrar 
Protocol (RRP), a commercial example of which is the Verisign Global Registry RRP. 
This link into the registry is how registrars monitor the status of registered names. Various 
protocols can be used, one example being the Verisign EPP (Extensible Provisioning 
Protocol), which is an XML implementation for domain name related queries. As known 
to those of skill in the art, suitable alternative or future protocols could be employed. 
[0017] The registry operator is contractually obligated to give all registrars equal 
access. For example, the ICANN (Unsponsored TLD) Registry Agreement provides in 
pertinent part: "Registry Operator shall provide all ICANN- Accredited Registrars that 
Q have Registry-Registrar Agreements in effect, and that are in compliance with the terms of 
U such agreements, equivalent access to Registry Operator's Registry Services, including to 

1 its shared registration system." The complete contract can be found at: 

4" 

http://www.icann.org/tlds/agreements/unsponsored/registrv-agmt-llmay01.htm 

CO 

-7 [0018] Because many registrars each have a high-speed, efficient communication link to 

p! the registry, and assuming each employs an efficient communication protocol, the winner of 

P the name-grab race is still basically left to chance. To be reliably successful at acquiring 

O domain names, a registrar needs a way to get ahead of its competitors. 

M 

Summary of the Invention 
[0019] One basic underlying aspect of the present invention employs a domain name 
"monitor and acquire" method. That method involves monitoring the databases to "watch" 
selected domain names, with enhanced frequency of "pinging" as the expirations draw 
near. This is done by pinging the WHOIS database at the registry that administers the TLD 
in which the domain names are registered. 

[0020] Second, considerable improvement is achieved over the basic monitor and 
acquire method by "partnering" (actually a contractual relationship) with one, or 
preferably, multiple registrars, and employing all or a portion of their direct registry access 
bandwidth. The aggregate effect of multiple connections to the registry should improve 
performance in terms of timeliness of information and efficacy of any acquisition efforts, 
toward the goal of obtaining information on deleting (and therefore available, or soon to be 
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available) domain names ahead of competing registrars or the would-be registrants using 
their registry connection. 

[0021] A third, and quite different, model is this: the monitor and acquire service is 
integrated into the registry itself, with the cooperation of the registry operator. While the 
singular form of "registry" is used herein for clarity of explanation, the invention is equally 
applicable to multiple registries. 

[0022] Implementation is simplified and efficiency is improved by integrating the 
monitor and acquire services directly at the registry of interest. This obviates the need for 
multiple registrars (or other registration service providers) to constantly "ping" the 
authoritative database so that loading on the system is relieved. Registrars and other 
retail-level competitors can avoid the trouble and expense, and especially uncertainty, of the 
present race-to-grab a name. For example, some of these retail-level players offer a 
"money back guarantee" to their customers; triggered if the retailer fails to register the 
desired name when it becomes available (usually because a competitor registered it first). 
[0023] According to the present invention, any and all domain name retailers, such as 
existing registrars, can participate much more simply in providing monitor and acquire 
domain name services. The retailer can still offer such services to its customers under the 
new model, generally through its Web site. Customers can sign up to have the status of a 
desired name monitored and the name acquired or re-acquired automatically. The retailer 
no longer needs to perform the monitoring and acquiring steps itself. Rather, the retailer is 
acting like a reseller of these services. The services are actually provided by a single (i.e. , 
only one is permitted per registry) intermediary entity or software routine implemented at 
the registry. The intermediary, or the registry implementing software consistent with the 
present invention, maintains databases of all domain names for which any "retailer" 
requests monitoring or acquisition on behalf of its customers; together with information 
identifying the customer. 

[0024] According to another aspect of the invention, the intermediary or implemented 
software "watches" the registry to detect availability of a desired name and register the 
domain name immediately upon it becoming available. The "watching" can be effected 
various ways, for example through "push" updates from the registry or "pull" queries into 
the registry database from the intermediary. 



Portlnd2-4322327_l .DOC 10720-00004: 1 



8 



[0025] When a desired name becomes available, it is automatically acquired by placing 
a hold or immediately registering the name to the customer entity listed in the database. 
The customer and or the associated retailer are then notified. Payment for the registration 
is prearranged so it too can occur immediately and automatically. This invention obviates 
the expensive race now going on to acquire recently available domain names. If an 
intermediary is involved, the intermediary will always effect the registration, as it has no 
direct competition and in any event gets notification ahead of others because of its direct 
communication link into the registry (which may be effected on the same machine as the 
registry). 

[0026] One embodiment of the present invention can be directed to providing 
monitoring and acquisition services for receiving from a registrar a request to acquire a 
O desired domain name, receiving from a registry a pending delete notification for the desired 
u domain name (the pending delete notification preceding a public delete notification) and 
? requesting acquisition of the desired domain name for the registrar. One embodiment of a 
*fi system designed to provide these and similar services can include an acquisition database 
r containing an acquisition request from a specific registrar to acquire a registered domain 
name as soon as practicable. An acquisition front end system can be provided to receive 
P the acquisition request from the specific registrar and to store the acquisition request in the 
O acquisition database. Also, an acquisition engine can be integrated with a registry system 
to receive from the registry system a pending delete notification for the domain name. The 
acquisition engine can be integrated as hardware, software, or both. The pending delete 
notification can precede a public delete notification issued by the registry system. The 
acquisition engine can then access the acquisition request from the acquisition database and 
request acquisition of the domain name for the specific registrar. 
[0027] The domain name monitoring and acquisition services and system described 
herein can be offered as a viable, independent business tool. Primary customers of a 
business employing the present invention would be domain name registrars and resellers 
(such as in a thick registry system). In this capacity, the registrars essentially would be 
reselling the services to their customers so as to provide the customers a more reliable way 
to acquire a newly available domain name. Fees could be charged for placing an 
acquisition request. Because of the reliability of the present invention, a money-back- 
guarantee could also be offered at low risk to the business. 
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[0028] Additional aspects and advantages of this invention will be apparent from the 
following detailed description of preferred embodiments thereof, which proceeds with 
reference to the accompanying drawings. 

Brief Description of the Drawings 
[0029] FIG. 1 is a simplified block diagram of a domain name management and 
acquisition system according to the present invention. 

[0030] FIG. 2 illustrates a procedure for a registrar to obtain domain name acquisition 
services for a customer consistent with the present invention. 

[0031] FIG. 3 is a schematic of the various communications and interactions between 
domain name acquisition engine, a registrar, and a registry according to the present 
invention. 

[0032] FIG. 4 is a flow diagram providing a logic overview of the process of FIG. 3. 

Detailed Description of Preferred Embodiments 
[0033] When referring to the following in Figure 1, the term "systems" is meant to 
mean one or more, routers, layer two or three switches, computer systems, APIs, and 
software. In Figure 1, a Registrar computer 100 communicates with a Registry system 
102. The Registry system includes a Global Registry RRP front end 110. The front end 
110 communicates with a Global Registry SRS Database Management System 112. The 
SRS database itself is illustrated as 114. This database would be the unique global 
("authoritative") database for the gTLD space assigned to the Registry system 102 operator 
(e.g. , ".com"). 

[0034] For ease of discussion, a preferred embodiment of the present invention is 
described in terms of a system integrated at the registry level. This system is described as 
receiving input from one or more registrars. As will be readily apparent to those of skill in 
the pertinent art, a system consistent with the present invention can be integrated with the 
registry as hardware, software, or both. Similarly, the present system can operate in a 
thick registry system (in addition to a thin registry system) by receiving input directly from 
potential registrants, rather than from a registrar. These alternative embodiments are 
equally within the scope of the present invention as set out in the attached claims. 
[0035] The Registrar 100 also communicates with an Integrated Domain Acquisition 
Service ("IDAS") front end computer 116. This computer can implement appropriate 
communications protocols (many of which are known; with various levels of security), 
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including, for example "Extensible Provisioning Protocol" (EPP). EPP is a connection- 
oriented, application layer client-server protocol for provisioning and management of 
objects stored in a shared central repository. It employs the XML schema semantics for 
domain name related queries to the repository. 

[0036] The front end computer 116 is coupled to an Integrated Domain Acquisition 
Service ("IDAS") acquisition engine and database management system 118. The 
acquisition system, in turn, communicates with an Integrated Domain Acquisition Service 
("IDAS") database 120. The various elements of the system 102 can of course be 
implemented in various ways, using more or fewer computers than illustrated; in a 
distributed network. One essential characteristic is that the system should be accessible by 

M Registrar 100 at all times, and preferably accessible to many registrars. This is the primary 

O 

D function of the right side of the diagram, comprising the Global Registry front end 110, the 

Jji Global Registry database management system 112, and the Global Registry SRS database 

{ 1,4 

Bl [0037] The elements on the left side of the diagram implement an Integrated Domain 

y. Acquisition Service ("IDAS"). Here "integrated" refers to integration with the global 

E registry as further explained below. In the past, domain name acquisition services were 

H provided by registrars or other parties using their own systems, separate and remote from 

o 

H° the global registry. We also use the phrase "domain acquisition services" to refer to 

services distinct from the routine registration of an available domain name. In particular, 
we use the phrase "domain acquisition services" to mean "acquiring" (by reserving, 
holding or substantially immediately registering) a domain name that had been registered, 
and recently became newly available, generally because the prior registrant did not timely 
extend (renew) the registration. 

[0038] Figure 1 illustrates the following data paths: 

"A" The current (typically SSL) RRP communications channel connecting 

the Registrar 100 to the Registry System 102 via the global registry RRP 
front end 110. 

"B" Any communications paths between the RRP front end 110 and the 
database processing environment 112 for the Shared Registration 
System. 
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"C" Any communications paths between the database processing 

environment 112 for the Shared Registration System and the actual SRS 
database 114. 

"D" The (preferably SSL EPP) communications channel connecting the 

Registrar 100 to the IDAS front end 116. 
"E" A communications channel connecting the IDAS front end 116 to the 

DAS acquisition engine and database management system 118. 
"F" A communications channel connecting the IDAS Acquisition Engine and 

Database Management System 118 to the IDAS database 120. 
"G" A communications channel from the Global Registry SRS database 

Management System 112 enabling notification of deleting domains to the 
IDAS Acquisition Engine and database management system 118. 
"H" A communications channel between the Global Registry SRS database 

Management System 112 and the IDAS Acquisition Engine and database 
management system 118. 
[0039] These links implement the necessary access to the RRP/SRS (112) to issue 
commands needed to register desired domains on a Registrar's behalf. "Desired domains" 
are the names stored in database 120 to be monitored and acquired if and when available. 
Commands for this channel preferably should include RRP "check domain," RRP "add 
domain," RRP "modify domain commands," and possibly other commands necessary to 
modify the SRS Registrar field. 

[0040] Figure 2, which illustrates a procedure for a Registrar to obtain a IDAS 
subscription, is as follows. A customer 200 makes a request to a Registrar 100 for DAS 
service. In a presently preferred embodiment, the Registrar establishes an EPP or similar 
connection to the IDAS front end and issues a "DAS check request" 204. The "DAS check 
request" will query the RRP/SRS 206 for the current SRS status of the second level domain 
name (SLD) . If the domain name is currently registered, signified by a message 210, it is 
eligible for a DAS subscription. The Registrar can then issue a valid "DAS add request" 
212. The front end 116 causes an appropriate entry in the IDAS database (see Figure 1). 
When the requested domain name becomes available, the IDAS system sends an 
"Acknowledge DAS Success" or similar message 214 to the Registrar that requested the 
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service. That registrar then notifies its customer, shown as message 220, typically via 
email. 

[0041] The "DAS Add Request" 212 requires the Registrar to populate a data set, for 
example, through the EPP interface, with information previously supplied by the requesting 
customer 200. This information is a data escrow containing the required registration 
information for the desired domain name. The data set also contains flag fields indicating 
who will provide the email notifications, the intermediary or the Registrar. At any time 
during the DAS subscription period, the Registrar can update or modify the registration 
information in the DAS database. Once the desired registration occurs, the Registrar, and 
optionally one or more customer defined e-mail addresses, will receive notification by 
e-mail of the successful operation. Other methods of customer notification can be used 
(e.g. fax, wireless, pager, vm, voicemail, snail mail, etc.); the method is not critical. 
Upon receiving the notification 214 the Registrar will update 332 the WHOIS record 340 
reflecting the new registrant information originally supplied from the DAS database 120. 
[0042] Once a Registrar has issued a successful "monitor and acquire service add 
command," information about the monitor and acquire service is stored in the IDAS 
database. Fields in the monitor and acquire service database will include the SLD and 
TLD, the sponsoring Registrar for the future domain name registration, complete registrant 
and contact information, from one to thirteen name servers, date of the monitor and acquire 
service subscription creation, date of the monitor and acquire service subscription 
expiration, a status field indicating that the intermediary will perform customer notification, 
up to three e-mail notification addresses, and the status of the monitor and acquire service 
(pending or complete). 

[0043] Figure 3 depicts communications and interactions between the Registry and the 
intermediary's Acquisition Engine. In a prompt and preferably real time manner, the 
Registry 112 will transmit a message 310 to the IDAS Acquisition Engine 118 indicating 
that a domain name is ready to be released and will be in a state where it can be 
re-registered. This is shown as a "pending delete" notification 310. These messages are 
not necessarily the Registrar's RRP delete commands, but follow the Registrar's RRP 
delete command when the Registry is about to initiate a final purge process making the 
domain name available for re-registration. 
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[0044] Responsive to a "pending delete notification" message to the IDAS Acquisition 
Engine, the Acquisition Engine checks the domain name 312 against the monitor and 
acquire service subscription database 120. If an IDAS subscription is held on the domain 
name, the Acquisition Engine will establish an RRP connection 314 on the Registrar's 
behalf. This connection or message corresponds to channel "H" as illustrated in Figure 1. 
Next, the Acquisition Engine acknowledges receipt 316 of the original ("pending delete") 
message to the Global Registry system 112 and the Registry completes a purge of the 
subject domain name. Now the Acquisition Engine issues an RRP "add domain" command 
318 to re-register the domain name (to the new registrant, customer 200). 
[0045] If an IDAS subscription does not exist in the IDAS database for the domain 
name identified in the "pending delete" notification, the Acquisition Engine simply replies 
with an acknowledgement 316 to the Registry, and purging of the name proceeds. No 
attempt to register the domain name is made by the Acquisition Engine. All registrars, 
including registrars other than 100, will learn of the deletion when they next update their 
records against the SRS database, and are free to register the purged name; in the 
conventional manner. As may be observed in view of this description, no registrar will 
beat registrar 100 in registering the newly released name, as registrar 100 is using the DAS 
system integrated with the registry itself. 

[0046] Referring again to Figure 3, once a successful RRP add domain name command 
has been issued, the Registrar will receive notification 330 of the desired registration. The 
Registrar will then update 332 its WHOIS database 340 by modifying the record 
corresponding to the name just re-registered. The registrar can notify 350 the customer 200 
or, alternatively, the option can be implemented to have the IDAS effect the customer 
notification 360. If the acquisition system is employed in a thick registry domain name 
system, the registry provides the WHOIS update 332 to a registry WHOIS database (not 
shown) as opposed to the registrar WHOIS database 340. 

[0047] Figure 4 is a flow diagram providing a logic overview of the processes described 
above. It illustrates the foregoing processes in an alternative format, but it need not be 
separately described further. 

[0048] It will be obvious to those having skill in the art that many changes may be 
made to the details of the above-described embodiments of this invention without departing 
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from the underlying principles thereof. The scope of the present invention should, 
therefore, be determined only by the following claims. 
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